MCP Server #1113
MCP Server #1113
Conversation
…n MCP tools and handlers
…r live check tool
…metric, search, and span tools
…icies and preprocessor support
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1113 +/- ##
=======================================
+ Coverage 79.2% 80.3% +1.1%
=======================================
Files 103 105 +2
Lines 7992 8126 +134
=======================================
+ Hits 6332 6528 +196
+ Misses 1660 1598 -62 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| /// - `get_entity` - Get a specific entity by type | ||
| /// - `live_check` - Validate telemetry samples against the registry | ||
| #[derive(Clone)] | ||
| pub struct WeaverMcpService { |
There was a problem hiding this comment.
I know this may be crazy, but is there any chance we can re-use the vanilla API server and just "wrap" API methods with MCP definitions instead of having two instances of serving / application flow?
I think there's a LOT of commonality between the two pieces, and it'd be ideal if we could share it.
There was a problem hiding this comment.
Wrapping a web api with mcp is an anti-pattern. I did move all the internals of search and get* into the weaver_search crate to make it common. I think it's likely they'll diverge, for example I'm experimenting with multiple tools for live-check.
There was a problem hiding this comment.
Wrapping a web api with mcp is an anti-pattern.
Interesting - tell me more?
I'm suggesting MCP is basically API++. Where we can delegate to API functions we should. If you add more that's great.
E.g. I'd be nice if we had a consistent "AppContext" structure that has our Arc<State> in it and a set of methods on this that both the MCP + API server would use.
I'm not suggesting we directly call the API from MCP - just that we take small amount of time to but in a shared abstraction they can both use to interact with a 'served weaver' thing.
There was a problem hiding this comment.
Actually @lquerel first pointed this out to me in this comment #798 (comment) where I had a similar idea to you. Subsequently I have read this same advice quite a few times. The video link is good, there's also a good reddit thread if I recall correctly.
Did you see that I moved the common internals to the weaver_search crate?
There was a problem hiding this comment.
Thanks for the link! I'll take a look.
Did you see that I moved the common internals to the weaver_search crate?
I did not, but that's great!
I was actually thinking of naming the create weaver_debugger or some such - i.e. if I were to add "jq", "rego" or "jinja" debugging tools, what crate should that live in?
2 participants
This PR adds
weaver registry mcpan MCP (Model Context Protocol) server that exposes the semantic conventions registry to LLMs. This enables natural language queries for finding and understanding conventions while writing instrumentation code.searchget_attributeget_metricget_spanget_eventget_entitylive_check